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ABSTRACT 


In 1977 the ACM Special Interest Group for Grapnics 
(SIGGRAPH) formed the Graphics Standards Planning Committee 
(SPC) to develop a standard for the industry. The result of 
their efforts was tne CORE grapnics system. fTnis study 
discusses that system and the issues involved in its 
creation. It describes Bell Northern Researcn’s approacn to 
implementing CORE with their Virtual Graphics Machine (VGM). 

Tne installation of VGM at the Naval Postgraduate 
School on a PDP 11/58 with the RSX—-11M operating System is 
ieeerioead aS well as the initial efforts to expand it to 


drive the Ramtek RM-94¢@ Graphics Display System. 





[l. 


iv 


TABLE OF CONTENTS 


INTRODUCTION eeeeeeeee@eeee8e3«#e6esete#eeeeee 


HISTORY eeertrteeeeteoeeeev#eeee#eee © 0 8&@ @ @ @ 


A. 
B. 


eee @oee@e7eeee#eeee#e8eef fe ¢ @ @ 


THE PROBLEM OF NON-STANDARDIZED GRAPHICS SYSTEMS. 


FORMATION OF THE GSPC ....... 


ISSUES CONSIDERED IN CORE DESIGN 


A. 


B. 
Ce 


FORMAT OF CORE e@e@eeeeee#see8?ee@#*?eeee28ee#8e3#8frke@emtrmUtmUcCOUCUMCOMUCCUCOHUCUCUCMhrChCOrCUCOrChUCMOChUCUCUhCUMhHLUMCHLUh!]}HLUMhHMhC COC OhUhHhUcHhUhS 


DEGREES OF PORTABILITY ....... 


e@eeteertee7#5#eteteeeeee @ 


SCOPE OF CORE eeeoeoeee#e#eeev#s##e#e#eee#*e#?e8eeeeee7e#eee#ee#eeetkt ee © 8 ¢ @ @ 


TTEW IG Mom eMeCONCEPTUAL MODEL ......cccccccccses 


GRAPHICAL DATA STRUCTURE ..... 
Mei h DBI MWS iadevcisicleuels « 6 oss ee 0 6 0 


TWO AND THREE DIMENSIONAL GRAPHICS .....ccccrvecee 


VIEWING TRANSFORMATIONS ...... 


LEVELS OF CORE eeeeteeee27eee#e#eeeeee#et3es#e7eee#e#eeeeee8keee8eee80e28080e @ 


SORE osm me DESH PUTON scicscies s 3 ee 


A. 
Be 


OVERVIEW eeeeeee#noeeese8ee8eeee7neeeee7eeeeememmemUmcUMmCUCOCOHrlmUCUCOUCUMhOhUCUCUCOOmCUCUCPOmhChUCUCOhChUCUcMOhUCUCcCOhUchHmhUh Ohh 


OUTPUT PRIMITIVE FONCTIONS ... 
SPU MEIN /tiS: ielelelclel elles « 6 6's \slele els s ses 
Bereta si, Omureiotaneusiaialiadensiisloleisiieiie) susie 
VIEWING TRANSFORMATIONS ...... 
EO LeeE Re WIG sc. sss eee ee 6s 
ever OF (CORE 6 cs «6 656 Sle e100 
ENVORONMENT INTERFACE PROBLEMS 


@eeee7ee#eeee?eee8e8?8080 8@8080 ¢@ @ 


ie 


ay 





VY. 


VI. 


nl . 


THE VGM BPPROACH TO CORB ..ceccccrcecccevecesosecesees OF 
A. FUNCTIONAL DIFFERENCES . nce cc ccc ccc ccc cccceesceses 3g 
1. SGRMEMTETHON 2... ccc ccc cc cece cee rcscsvccsceses SY 
Se ANGe AP OUTS) (Se cic ee ee ee ee AG 0 Die Gcadboro Ce eccecvccee 40 
5S. The Viewing Surface ceccccccccecscccsccece Seo = 
SOO d] Nast OM IY SUCIMS faliecscelec ccc cose ce cccccves £5 
De Transformations wc ccccvccrervees eiaietonaiee eo siiey enon 435 
Sree f Center a ta OMS Uelssie 66 ses c ccs ccc es cc cece e ss £4 
TU PIEGHOOMIDIGU Vas oie) 6 sc ce 6 sic es 6 o0-ss eee Se are eee 46 
B. CORE FUNCTIONS NOT IMPLEMENTED BY VGM .....2.-.2.. 48 


C. FUNCTIONS IMPLEMENTED BY ¥GM NOT IN CORE 
SPECIFICATION *#*eoeee@eeesesecretete Geesseeetee#eeee@ee#e%#e#e?e?#6¢#6%#e¢eee @ 47 


DPR CL VES 6 eee coc cc eee cect cece ecto ec ee meese 40 

SS AGU DUNG ES Scio 5s wee ce ce cee cece cee wcec ccc csces SF 

Se OCNEP FEATUPES ccc ccceccsscccvcccvcccccsccsece SF 

D. EQUIVALENT FUNCTIONS WITH DIFFERENT NAMES ........ 49 
foe vist® DOWN CE! DRIVER 6 ccc ccc cc ccc ees ccc ccccccseses 

eee c  CHMNACTORU OTL CS “PRED SE 2... ccc cece ccs esccesee OF 


B. STREAM INFORMATION TABLE ....ccccccccccccccece tee. 5B 
C. RUN TIME INFORMATION TABLE .....ccccccccceccccce .. 51 
D. ROUTINES EXECUTING VGM PRIMITIVES ....cccceccccece 51 


BE. DEVICE INDEPENDENT LIBRARY OF SHARABLE ROUTINES .. 51 


F. DEVICE INDEPENDENT ROUTINES GENERATING INSTRUCTION 
CODES e@e@eeeeteeeeessset ee eeeoeesg@?@eeeoesgse@eeevek#erteseeee#ee#ee#ese?+s%tse &¢ 6 ¢ © @ 52 


RESULTS AND SUGGESTIONS FOR FOTURE STUDY ............ 54 
A. SOFTWARE eeeeeee?eseeeseereeteeesees#eseseeeeteeseeeeteee#ee¢ee¢¢ @ e® ees? 54 





Bee CORE EVALUATION @e*e@ee@e*ee@e%e@e?@ee¢eeoe¢e@ee@ewemUmcesemcaemlUCc OhOCmUCUCMOrhUCUCMMrhC RMrhCM MCU ][// HH HF HFT SF FC SF 


ae Portability eeeeeeee¢es##seeerternreeeteerteoeeetrteeeteeteeeee @¢ @ 


2. Implementation Effort 


Os Device Capability @eeoeeoeee7e7eees?eee7#tstee#e2e?e¢€?8ee¢e8@¢e¢80 8 @ 


4. CORE Capability 


C. OUTLINE OF CONTINUING DEVELOPMENT OF THE NPS 
SYSTEM @e@ee?#ee@e#8e#e?® @*eeee@e#e@ee?e?e?8eeeteeteee 8 


le VGM e@eee7ed#8?ee8e¢80080880080@6U8H86UMGMUCMOUCUC[CUM OCU HMChUCUCMUCUCUP;]/DUC HOU ]HUC HCC HU HODCUCUM ]U~COHSeeeeeoe#eseee¢ @ @ @ 


2. Device Drivers 


Oe Portability *@eees7e2##sseeetvs*eesteeo1ese+¢ ee emUmUMmUCOCUCOCUC}HCLhUMhHChUCUMhOOCUM!OCCUHhUMhUCUMhOHLhUMMhUCUcCOMrhUCUhHhUhFHhUhO 


APPENDIX A. IMPLEMENTATION OF VGM AT THE NAVAL 


POSTORAUUATE SCHOOL 2.0066 ss0 20 
APPENDIX B. CONSTRUCTION OF A DEVICE DRIVER FOR THE RAMTEK 


RM—-942¢ eeeoeee7?@#ee8eete#eteeeeeoeeeeeeneeeemUmcmUCUCOUCUCOmUCUCOrCmUCUCMOMrCUCCUM CUCM CUM OrChUCUCMOmrChUCUCMOMrChCUCUcCOMrUhHhUh]MhF 


APPENDIX C. PROGRAMMING WITH 


YGM @e@eeeee#28eee#8e#e¢*® 


BIBLIOGRAPHY Cee eee tee ee 28 0 8 Ss ee 6 ee 8 SS eee ee ees eee ee ers 


INITIAL DISTRIBUTION LIST 


=)f¢ 


26 
39 


61 


67 
8d 
86 


S7 





I. INTRODUCTION 


Computer graphics is a relatively young tecnnology and 
is expanding at an extremely rapid rate. As a recognized 
discipline, it marks its birtn with Ivan E. Sutherland’s 
SKETCHPAD, in 1962. As tne field has expanded, hardware nas 
developed along several different lines. The available 
devices range from computer driven mecnanical pen and tnk 
and photographic film plotters, to refresh display devices 
weere Gigital stored images are repeatedly painted on a 
television-like Cathode Ray Tube (CRT). ‘There are also 
storage tube displays wnere the CRT itself retains the 
image, thereby eliminating the need for storage and 
continuous refreshing. The latest development nas been the 
raster-scan devices where a matrix of intensity values is 
mieeput to a refreésh type CRT. 

The software supporting these various devices has 
developed along lines as diverse as the hardware. Despite 
wide variation in device capabilities there is a large body 
of graphics metnodology that is common to all display 
systems. The existence of this body of Shared technology 
has contributed significantly to the movement toward tne 
development of a software system that would be common 


throughout the community of graphics programmers. 





The concept of a standardized graphics system is not a 
new one. The pudlication of the ACM-SIGGRAPH Graphics 
Standards Planning Committee (GSPC) report in 1977, however, 
wes the first wid@ly acceptéd effort in the area of 
Standardization. This CORE graphics system is, as yet, only 
a proposal. CORE is envisioned by the GSPC to be a first 
step toward a true, industry-wide standard. Tne hope for tne 
current CORE system is that it will be implemented at a 
large number of computer egraphics installations and be 
subjected to a variety of applications. Such widespread use 
of CORE is the best way to fully challenge the proposed 
Standard. Extensive use of the system will build a 
comprehensive body of knowledge about it and should 
hignlignt its strengtnos and weaknesses. Bas@d on sucna 
experience the system can be revised and restructured as 
necessary until ultimately it is accepted as a viable 
industry-wide standard. 

This project is intended to be an initial step toward a 
tnorougen study of tne CORE grapnics system at tne Naval 
PoSteraduate School. The lone term goal of the research is 
to implement the GSPC proposed system on tne grapnics 
facility at the Naval Fostgraduate School and critically 
examine its performance. 

When this research was begun, exposure to CORE at the 
Naval Postgraduate Scnool was limited to tne information 


available in the literature. No version of it was 





operational at the facility. It was expected that the 
progress of the work would be slow while experience with 
CORE was being accumulated. Since this study was the initial 
step, the emphasis was placed on producing a good foundation 
for work that would follow. 

Naturally, the first step in the study of CORE was to 
implement aversion of it. Tne PDP-11/56 computer and RSX- 
11M operating system were the target environment for this 
phase. Tne CORE software was Bell Nortnern Researcn’s 
Virtual Graphics Machine (VGM), which was donated by that 
company to the Naval Postgraduate School for research 
purposes. A detailed report on the system installation is 
peesented in Appendix A. 

An intermediate e2zoal of the project is to extend the 
newly installed CORE system to a variety of devices. Toward 
this end the initial steps were taken to incorporate an 
interface with tne Ramtek RM-9490 graphics display system 
into the CORE software. Appendix 8 describes this portion of 
the research. 

AS part of building @ knowledge base “for later 
researcn, tne CORE system and its development are discussed 
in detail. The discussion is intended to give enouen ot an 
overview of tne system so that tne read@r will not need to 
refer to the source documents except for essential details. 
An examination of cre relationship between YGM 


implementation and the CORE specification is also provided. 
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A. THE PROBLEM OF NON-STANDARDIZED GRAPHICS SYSTEMS 

Until the mid 1970°s individual graphics devices were 
Operated with their own specialized software systems and 
their instruction sets were tailored to their own particular 
sapabilities. Programming techniques generally were 
constrained by the device characteristics. kven program 
Serpcture could be dictated by the available graphics 
system. Added to these restrictions would be additional 
requirements associated with installation computing hardware 
and operating systems. Such highly individualized equipment 
meant that e@ach eraphics system frequired specialized 
programs, and, in gen@ral, tnese were applicable for tnat 
installation and no other. 

aS steered of computer @rapnics eCxpanded, such 
limitations became a real liability. The inability to use 
one program at more than one installation meant tnat for a 
Ziven application a new set of software would nave to be 
developed individually for #ach combination of hardware and 
operating system. The issue of non-portadility eventually 
became an overriding concern of the industry. 

lg the programs for particular devices were 
individualized then so was the training of the programmers. 


Every device required users to nave fairly extensive 
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knowledge of its operation. Rather than concentrate on 
graphics ina broad spectrum, application programmers ezot 
involved in very low level, highly detailed programming for 
a specific device. This meant that much of the Knowledge and 
tecnniques developed by a programmer mignt be unuseable if 
the device were changed. Thus, a hardware cnange brought 
with it the necessity for an in-depth training program on 
the new device. Furtner, the programmer would now nave to 
keep the operating details of eacn device Separate in his 
mind. Confusion of sucn details is nignly conducive to tne 
tntroduction of additional bugs into programs. 

The prospect of working in a very restricted environment 
and of being required to assimilate and differentiate a host 
of idiosynchrasies, mnemonics, formats and operational 
details no doubt caused many potential grapnics application 
programmers to turn to other fields of Specialization. The 
graphics industry must count this to its detriment. 

Another problem, perhaps not quite as visible as the 
portability issues, out certainly aS worthy of concern, was 
the difficulty researchers in graphics had in building on 
one another’s work. AD application written, for example, for 
a storage tube display, would have to be completely 
rewritten for a raster device. The changes would be _ so 
numerous that equivalence of tne programs would de 
impossible to asSert. Also, the full duplication of a piece 


of work simply to adapt it to a different environment was a 
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costly process in terms of time and resources, both human 


and machine. 


B. FORMATION OF THE GSPC 

In more recent years, tnere have been some attempts to 
remove tne user from tne details of device operation by 
providing high level software. This typically took the form 
of a package of subroutines callable from some standard high 
level language. Such packages did remove tne need for 
programmer knowledge of some of the device operating details 
(though by no means all of them) but each package was still 
unique. Thus, though a step forward had been made, programs 
written from different grapnics packages were still not 
portable. 

Tne next step in tne evolution was to develop grapnics 
packages that were still specific for particular graphics 
devices but with a standard interface to the user program. 
This would allow transportation of user programs unchanged 
to installations where the ‘standard interface was 
implemented. This development was moderately successful but 
by this time, areas of research had grown up around 
particular classes of graphics devices. User’s of tne 
various classes of devices all had their own idea as to 
exactly what form the application program interface should 
take. Tnese opinions were widely varying and as always, were 


oriented toward the device capabilities. 
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Tne various “scnools” of grapnics researcn eventually 
realized that there were wide areas of agreement in their 
concepts of how a user should se@ a graphics system. fTnis 
led to the next evolutionary stride, the standardized 
graphics package. These types of systems were designed so 
that not only would tne application program/package 
int2rface be fixed, but the functionality of the package 
itself would be uncnanging. The need for individualized 
software for each particular device, nowever would not be 
removed. This task would be accomplisned by a ‘device 
driver and its interface with tne standard package would be 
a fixed entity. 

Tne first neaningful steps toward a standard grapnics 
package was the IFIP Working Group oie Graphics 
Subcommittee’s Worksnop on Grapnics Methodology neld in 
Seillac, France tn 1976. Based on experience with existing 
machine and device independent packages like GINO-F and GPGS 
the subcommittee laid tne groundwork for the movement toward 
industry wide standardization. Their contribution was’ to 
Outline and define the issues tnat had to be addressed if a 
Standard was to become a reality. AS alTeady discussed, 
their prime concern was tne issue of application program 
portability. Toward this end their recommendation was that a 
Study of the structure of application programs was 
indispensable, and that the results of such a study would 


drive the specification of a egraphics standard. Another 
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outcome of tne Seillac meeting was tne assertion that tne 
separation of operations concerned with creating a picture 
of an object from those concerned with manipulating tne 
object itself was essential. Lastly, the Workshop urged tnat 
a standard graphics system specification not stand alone. 
Alone with the detailed design should be included the 
methodology behind its development. 

In 1977 tne ACM Special Interest Group for Grapnics 
(SIGGRAPH) appointed a Graphics Standard Planning Committee 
to iesign an industry wide grapnics standard. Using the 
recommendations of the Seillac Workshop as a foundation, the 
svOPC designed tne CORE graphics system. Their specification 
for the system, and the methodology that led to it, were 
publisned in August 1977. An updated version appeared two 
years later tncoroporating the experience gained in the 


interim and extending CORE to raster devices. 
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III. ISSUES CONSIDERED IN CORE DESIGN 


——_ — ae = 


In the early stages of discussion, tne Grapnics 
Standards Planning Committee concentrated on clearly 
Serining th®ir goal. Tneir objective was to design a general 
purpose graphics system that would meet the needs of the 
majority of eraphicS programmers and would be Simple _ to 
install on most eristing interactive displays. 

It is essential tmat such a general purpose system ode 
Sumore). This principle was recognized by tne GSPC and 
Strictly adhered to. They targeted their efforts toward the 
Memential users with tne intention of promoting well- 
structured, comprehensible software. Syntax was considered a 
less complex and secondary design issue. Tne committee also 
sought to put definite bounds on the scope of the new 
system. Tne intention was to provide a system tnat would 
offer a wide range of capabilities, but not at the cost of 
losing its appeal aS a general purpose tool. Two tradeoffs 
meet «6©6CCONStantly cropped up before tne GSPC were simplicity 
vs. wide applicability and program portability vs. machine 


efficiency. 


A. FORMAT OF CORES 
Tne GSPC considered tnree approacnes to development of 


the core system. One possibility was to create a complete 
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new graphics language. A second choice was tO take an 
existing language and make tne core system an exté@nsion of 
it. The third approach, and the one finally settled upon was 
to build a package of graphics Subroutines. There are a 
number of advantages to the subroutine package as opposed to 
mmoaer of the alt@rnatives. The major benefit is that i1t 
requires no changes to either the language or tne compiler. 
System development, revision, and experimentation will have 
no effect on any otner software at tne installation. The 
primary limitation iS that the Syntactic Structure 15 
extremely limited since the only cnoice in tnis @rea is the 


approach to parameter passing. 


B. DEGREES OF PORTABILITY 

The degree of program transportability as measured by 
the type of required changes was broken down into three 
general categories: 

i) The absolutely portable program which when 
transferred fron one installation to anotner would require 
no Changes whatever to the source code. Such programs are 
the ultimate goal of any graphics standard. 

2) Programs that require only editorial changes without 
modification of Structure. This class of program would 
require adaptation to a new installation in much the same 


way that non-grapnics programs written in a nign level 
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language have to be modified when they are transported. The 
changes typically are tnose necessary to adapt to sucn local 
idiosynchrasies as different character sets. These changes 
do not require a grapnics programmer or a specialist in tne 
particular application. Many of them can even be automated 
On a reasonably good text editor. 

3) The least portable category of programs would be 
those where changes to the program structure itself are 
required. Such changes as naving to create a particular 
routine to draw an are to replace a single command required 
by a more powerful device fall into this category. Changes 
of tnis type may require a detailed knowledge of tne 
particular installation characteristics; even then they Can 
be somewnat difficult and nave a tendency to be error prone. 

Realization of the absolute portability goal, was not 
expected when the GSPC publisned tneir proposél. Tne 
immediate hope for the CORE system is that it will 
drastically reduce tne number of changes required in 4n 
application program when it is transported. 1 is 
anticipated that tne “routine changes of category 2 above 
will be required in source code but, as a minimum, the 


Structure of the source program should remain intact. 


C. SCOPE OF CORE 
Having established the form the roposed efaphics 


Standard would take, and tne results tnmat could be expected 
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from it, the committee set about defining the scope of the 
project. Recognizing the Seillac workshop’s wisdom, the GSPC 
focused on viewing as the essential part of any graphics 
System (its core, hence the name) and treated anything not 
concerned strictly with displaying information about. an 
object aS outside the scope of the standard. This iS not to 
Say that such issues as modelling or grapnic arts were 
ignored. The intent was to design a core viewing System 
upon wnich tnose functions dealing with abstract objects and 


relations between them could be built. 


D. VIEWING SYSTEM CONCEPTUAL MODEL 

Once the scope of tneir task was defined, the committee 
developed a model that would adequately represent their 
concept of tne viewing system of tne standard. The viewing 
system can be thought of aS a Synthetic camera positioned 
and oriented in a user defined “world coordinate system. 
The display on the output device would be a Snapshot of 
whatever was in tne camera’s field. 

Such an analogy fit well tne rules the GSPC aad 
formalized. Tne ‘grapnical world” was considered all of tne 
graphical data available to the System. What would Snow up 
On the output device would be a view of tnis world tnrouen 
the eye of the synthetic camera. The camera might be able to 
take in the entire Set of graphical data or only a portion 


of it, depending on the viewing parameters. To take an 


18 





imaginary Snmapshot, the sysStem would nave to be aware of the 
camera’s location in space, its orientation, and tne amount 
of a particular object it could actually photograph (i.e. 
its clipping volume). Furtner, at tne instant the snapsnot 
is taken, none of the parameters related to the object deine 
photograpned could change. It must be remembered tnat what 
is on the screen is only a part of the total information in 


tne grapnical world. 


E. GRAPHICAL DATA STRUCTURE 

Besides deciding how to display an object in the 
eraphical world the committee had to establisn the 
merticular structure to be used to represent grapnical data. 
The simplest approach would be to nave no Structure at all. 
Either all of the graphical data is present and fixed or a 
new 2raphical world will have to be created. Thus, one could 
only build or erase an entire object. Onc displayed, there 
would be no changes to tne graphical world. Such an approacn 
is very easy to implement and storage is not a major issue, 
meee after the Snapsmot iS taken, tnere is no further need 
of the data. Such a system is ideally suited to hard-copy 
plotters and Similar devices but its drawback is that it 
does not meet the needs of a large portion of graphics 
applications. 

Much of eraphics is concerned with buildine an object 


and selectively modifying only parts of it. This requires 
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femst, that the graphical data not be lost after it is 
displayed and second, tnat it be segmented in sucn a way 
that individual pieces can be manipulated. Since there is a 
considerable demand for sucn structuring, toe GS PC 
incorporated it into their standard proposal. Their concept 
igs that graphical primitives (line drawing, text, and marker 
placements) be grouped into indivisible and unchangeable 
segments. Tnese segments are then be combined to produce an 
entire obdject. Thus the picture can be modified by pieces 
through the deletion and addition of individual Segments. 

In the interest of economy and fleribility the CORE 
System also implements a form of tne Simpler unstructured 
option. For tne body of users concerned witn storage 
efficiency or naving hardcopy displays, it is possible to 
designate segments as temporary. A temporary ségment is one 
that would generate graphical output while it iS open, but 
once closed tne segment would be automatically deleted. The 
next new frame action will cause it to be lost altogether. 
Effectively, while the image is being created in the open 
temporary seement the eraphics syStem is unstructured. 

Another possible Structuring of zraphical data would 05be 
to use multi-level units to define tne grapnical world. In 
Such a syStem, a unit (analogous to a segment) would be a 
collection not only of primitives but also of references to 


Otner units. This approach was considered by the GSPC to be 
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to complex for the bulk of current graphics applications. 
There are many variations to its implementation, none are 
easily accomplished, and all require a great deal of 
bookKeeping overhead Since a change to one unit may ripple 
through several others that reference it. It should be kept 
in mind, nowéver, tiater, such a erapnicdal structure is 
desired it is possible to construct it using tne CORE 


system. 


F, ATTRIBUTES 

With the structure of grapnical data settled upon, the 
need arose for defining modifications to the described 
Soyect. Besides the primitive functions already mentioned, a 
graphics system must have a means of further describing 
toem. For example, a primitive like line’ mignt nave 
Characteristics such as dashed (style), red (color), and 
double thickness (widtn). Deciding now to incorporate suca 
attributes into CORE was another major issue facing GSPC. 
Some attributes naturally associate themselves wita 
primitives, like line style and width, while others just as 
naturally only apply to woole segments, sucn as viewing 
angle or clipping volume. A problem arises with attributes 
that are likely to be needed for botn primitives and 
segments. Color is a typical example. The ability to produce 
a drawing using lines of Several different colors mient 0be 


desirable. But if it is desired later in tne program to 
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change the color of all drawings to say blue, an ambiguity 
arises in now to nmandle tne multicolored segment. 

The GSPC felt that resolution of such ambiguities within 
CORE would take away from the simplicity of tneir system. 
Therefore they established the rule that no attributes would 
be snared. Attributes would be specific for primitives only 
or for segments only. The former would be ‘Static 
attributes and be unchangeable for a primitive once 
declared. Segnent attributes, on the other nand would not be 
50 restricted. These ‘dynamic attributes would be 
changeable to meet tne user’s needs at any particular place 
in the progran. 

The decision aS to just which attributes would be static 
and wnich would be dynamic were based on two criteria. Tne 
first being that primitive attributes would be those things 
that would nornally be recorded by a snapsnot of a 
particular object. Attributes pertaining to tne image as a 
whole would be segment attributes. Tne second criteria was 
that an attribute would be dynamic, ({.e. a segment 
attribute) only if most medium performance, refresned 
display device architectures supported Cnanging toe 


attribute with reaSonable eaSe and efficiency. 


Ge TWO AND THREE DIMENSIONAL GRAPHICS 


Alone with the questions of graphical data structure, 


tne issue of now to treat two-dinensional and three- 
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dimensional grapnics in a single standard had to be decided. 
Initially tne inclusion of tnhree-dimensional grapnics was in 
question since it necessarily would add complexity to the 
System. It was decided that the need for three-dimensional 
graphics was great enough that its exclusion would restrict 
the applicability of the standard to an undesirable degree. 

A more subtle question than SD inclusion was whetner_ to 
treat 2D grapnmics as a subset of SD or to nandle the two as 
disjoint sets of operations. The advantage of disjoint 
treatment is tnat tne 2D expression would not be 
unnecessarily complex since SD information would not have to 
pe carried witn tnen. On tne otner nand a large portion of 
the system’s routines would have to be duplicated, one group 
Specialized for 2D) manipulation and anotner for SD. 

The GSPC chose the subset approach in the interest of a 
unified treatnent for all images. To foster simplicity in 2D 
graphics, they established tnmat the z axis coordinate would 
automatically default to tnat of its last specified value 


when fitting 2D operations into the SD format. 


H. VIEWING TRANSFORMATIONS 

One of the most difficult issues for tne GSPC to decide 
was how to treat viewing transformations of an object. There 
are a large number of approacnes to this problem and all 
have a certain amount of merit. When considering this 


particular question the committee chose to aim for maximum 
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System generality. Toward this end, they establisned four 
criteria. The first wasS that any viewing transformations to 
be performed would be declared before description of a 
particular object. No transformations within a segment would 
be allowed. Secondly, two-dimensional transformations would 
be upward compatidle to three-dimensional ones. Third, all 
general planar projections would be possible to implement. 
Mourth , parallel and perspective projections would be 
consistent. 

In tne discussion of viewing it is necessary to go dack 
to the synthetic camera model. In order to maximize 
Menerality of tne viewing aspect of CORE tne parameters 
under investigation were those concerning the location of 
Pee synthetic camera in space and tne location of tne 
viewing plane. The orientation of both the camera and the 
Veeewing plane must also be considered. It snould be apparent 
that the most flexible viewing system is the one that allows 
moe orientation and any location for both the camera and the 
viewing plane. Restricting the positioning of one or both, 
limits the allowable viewing pyramid and results in failure 
to meet one or more of the established criteria. 

For example, suppose tne view plane were restricted so 
that it must always be normal to the direction in which the 
Somerd is aimed. In such a case’, oblique perspectives are no 


longer possible, which is a violation the third criterion. 
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I. LEVELS OF CORE 

One of the final issues to be resolved was tne structure 
of the CORE standard itself. The question was whether to 
establish a single monolithic standard or to allow a number 
of Standard subSets of a parent system. Realizing that a 
very extensive system might be well beyond the neéds and/or 
masources of many installations, the GSPC settled on a three 
level structure. The lowest level would be restricted to tne 
most basic needs of most users, Stressine ease of 
implementation as well as economy of computing resources. 
The upper two levels include more features and a higher 
capability with correspondingly more Git ficult y in 
implementation. Bach upper level of CORE includes all of the 


features of tne level below it. 
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IV. CORE SYSTEM DESCRIPTION 


A. OVERVIEW 

In the previous chapter most of tne basic terminology of 
CORE has been introduced. In this chapter tne system itself 
is woscussed in aetail, but before doing “so, more 
terminology nust be introduced. Tne information displayed on 


basic building blocks of pictures afe output primitives. an 
@rvput primitive is a line or sequence of itiines, a non- 
drawing move of the cursor, a marker placement, ora string 
me vext. A number of output primitives are grouped togetner 
to form a segment. Each segment defines a single object and 
a combination of one or more objects defines an images. fhe 
view of an image can be tnhougnt of as a imaginary camera 
Snapshot of it. To obtain a 3-D projection of an image the 
user specifies tne imaginary camera position, type of 
projection (perspective or parallel) and where on the 
display surface the object is to appear. Different views are 
obtained by ‘moving the synthetic camera in space relative 
te the stationary object. After the view of an image iS 
determined the graphics system must map it onto the 
particular device selected to show it. The CORE system does 


this using two coordinate systems. Objects and images are 


created in a user defined, previously Specified world 
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oordinate System. Within this coordinate system the part of 
the total image that is to be displayed is framed by a 
window. The World Coordinate System is mapped by CORE onto a 
set of normalized device coordinates (NDC). NDC 
Specification defines the viewing area on tne selécted 
graphics device that will be used. NDC’sS are specified as 
fractions of tne total available display widtn and heignt. 
The window and the visible section of the image in it are 
mapped to the corresponding location in the normalized 
device coordinates. Once the image is in in terms of tne NDC 
it is a simple matter for tne CORE system, knowing tne 
Mmerticular device characteristics, to translate it into a 
picture on the screen. 

Any graphics system must have a neans of controlling its 
operating environment. In the CORE system this is 
accomplisned by: 

1) turning clipping on or off 

2) selectine view surfaces for output 

3) setting initial values for segment and 
primitive attributes. 

4) establishing error handling mechanisms 
To support the control functions the application program is 
Ziven tne capability to inquire about tne system status, 
variables and device capabilities. There is a new frame 
Function for screen clearing and a capability for grouping 


changes to the picture. 
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UUCpUGeDrntmcIvye wwe ulons May be referenced either by 
a segment identifier or a special pick-id name. The pick- 
dja is used in conjunction with a pick device, which will be 
discussed later in the chapter. 

To allow utilization by tne system of specific nardware 
and installation features, there is an escape mecnanism. It 
is a standard, rigorously constrained function tnat allows 
tne CORE systen to take advantage of tne non-standard 
capabilities of its environment. Use of the eScape has a 
feece in that it takes away from the portability of the 


application program. 


B. OUTPUT PRIMITIVE FUNCTIONS 

Output primitive functions are the operations the 
programmer uses to «descride objects in the develce— 
independent World Coordinate System. Invocations of tnese 
functions are gathered into Segments as drawing commands. 
Primitives work from the current position (CP), which is a 
Gaewing location in world coordinates. It is simply a 
Starting point for application of the function, and is 
initialized to the origin upon Segment creation. 

There are five output primitives: single and multiple 
line drawings, text display, and single and multiple marker 
placements. These are only sligntly different for tne two- 
and three-dimensional versions. Coordinate positions may de 


meet ied as Clther relative or absolute, but tne former is 
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merely a notational convenience. It does not necessarily 
generate a relative positioning command to the nardware. The 
concept of a marker in the CORE system is Simply a 
designation of a position in world coordinates. A particular 
character appears on the view surface to indicate this 
position but in world coordinates there is no such 
character. 

Beree ®inds of text are supported by tne CORE system 
Output primitives: String precision, character precision 
and stroke precision. Tne main purpose of string precision 
text fe whoOwecupprgy Lovormation to the operator. Its 
Peneration is simple and efficient. Character precision text 
is used when it iS important that a character string occupy 
[mores i~ndted space, a plot aris, for example. String and 
character precision are also referred to as low and medium 
quality text, respectively. Both medium and low quality text 
output primitives take advantage of hardware character 
memerators, if available. Stroke precision, or hign quality 
text requires a different approach. Here, tne string is 
treated as if each line of #ach character were generated by 


Software in the CORE system. 


C. SEGMENTS 
Segments are® created in the applications program. 
Creation of a segment follows a simple sequence. Tne World 


Coordinate System is defined and normalized device 
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Soordinates are specified. If desired, tne syntnetic camera, 
discussed earlier, is positioned to establish the view or 
moe object. Next, a segment is “opened and S the “object 
described using the output primitives. After completing the 
object description, tne segment must be closed §. To modify 
a piece of the picture a segment is deleted and a@ new one 
created to replace it. Segments are of two types: 1) 


2) temporary, which are most often uSed by plotters. AS one 
might infer, temporary segments are used only once to create 
a display and then are discarded. Retained Segments are kept 
by the CORE system until specifically deleted. Temporary 
Sezments have the advantage of economy of memory 
utilization. A segment’s type is establisned when it is 
created and remains unchanged for the lite of the Segment. 


Copying one segment into another or invoking one segment 


from another is not permitted under the CORE system. 


D. ATTRIBUTES 

The effects of output primitives are modified by 
assigning attributes to tnem. For example, the primitive 
“line” has an attribute “linestyle” which has values “solid” 
and “dashed”. Other attributes that doply to primrtives are 
color, character size, character precision, linewidth and 


more. 
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Segments, like output primitives, also nave attributes. 
These control such things as a segment’s visi oli ty, 
highlighting within tne segment and its detectability by a 
pick device. This last is a particularly important segment 
attribute. When a Segment is detectable and a pick is 
enabled, the device can sel@ct a primitive from tne segment 
and return to the application program both the segment name 

erie LHewexcept.on Of type, segment attributes are all 
“dynamic in that they may be changed after the segment has 
been created. If tne user does not specify attribute values 
prior to segment creation, tne CORE system provides a set of 
@eraulit values. 

Segments are assigned attribute values froma table of 
current attribute valueS maintained by the system. The 
application program has the capability to interrogate and 
change attributes. For primitive attributes changes can only 
be made while tne segment iS open; segment attributes, on 
the other hnand, may be changed at any time. A single 
attribute cannot apply to both primitives and segments. If 
certain attributes are not Supported by hardware, tne 
options are to either simulate taoem or force a reference to 
an error handling routine. The choice is installation 
dependent. 

Besides segnent and primitive, attributes Can be 


Classified by tne ‘Space in which they operate. For 
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seamele, text “dttribuves describe the text regardless or its 
location or orientation. They are said to define 
characteristics in ‘object space. On tne otner nand, line 
attributes such as style and width are related to views of 
objects. Depending on the location of the synthetic camere 
these attributes of an odject may appear different for tne 


Same value. They are Said to operate in the ‘picture space. 


BE. VIEWING TRANSFORMATIONS 

A viewing transformation accomplisnes two tasks: it 
specifies how much of the world coordinate space is visible 
and et maps visible world coordinate pictures eG 0 
normalized device coordinates. The viewing transformation 
takes a world coordinate volume (a clipped portion of a 
complete diSplay) and projects it onto a view plane in world 
foorainates defined by a window. Tne projection is then 


mapped into a normalized device Coordinate viewport, and 
finally to the physical device coordinates. The core system 
avolds a4 problen that nas occurred in tne past where two- 
dimensional objects required different treatment. 2D objects 
are treated as a subset of the SD odjects. When a Zz 
component is not specified, a default to the Z component of 
the current position is effected. : 

Window rotation or inclination 15 a common requirement 


for many applications. In the CORE syStem the concept is 


Bepeemented using aview-up vector. This vector simply 





points to tne “straignt up direction for tne window with 


respect to tne world coordinate orthogonal X, Y, and Z axes. 


F. INPUT PRIMITIVES 
Six types of input devices are supported by tne CORE 
system: 

PICKS: identify an output primitive by its segment 
name and pick-id. 

LOCATORS: provide world coordinate values for a position 
on the view surface. 

VALUATORS: provide a Scalar value. 

RETBOARDS: provide character strings. 

BUTTONS: provide a means of selecting from several 
mvernatives. 

Sr nOKES : provide a series of positions tO the 
application program in normalized device coordinatés. 

Input for interactive graphics is accomplished through 
logical input devices. These devices are a specified 
abstractly in the application program. The program defines 
and controls them in a way unaffected by the hardware. The 
CORE system’s task in tnteractive grapnics iS to connect 
logical input devices to an available piece ot hardware that 
Maeereaccomplish the desired function. Logical input devices 
may be manipulated in the following ways: 

1) Inittialization/ termination 


2) Enabline/disabling 
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3) Event queueing/ dequeveing 

4) Sampline 

5) Associating sampled and event causing devices (this 
ties values provided by sampled devices to events caused by 
event-generating devices) 

apeescno control 

Logical input devices fall into two mutually exclusive 
Categories. They are either sampled devices or event causing 
devices. SUGRome.  DirCH ye See wWboadrd dnd button are event 
venerating devices, locator and valuator are sampled 
devices. Event-causing devices provide signals to tne 
application program. For @ach event, an event report is 
created containing data related to the State of the device 
ar the time of tne event. Tne CORE system enters event 
reports in an event queue for later use by the applications 
program. To get state information about sampled devices, the 
moprrcation program must query tnem. These devices do not 
generate event reports. A standard feature of tne CORE 
meeecem is to echo automatically all operator interactions 


unless this function is specifically deactivated. 


G. LEVELS OF CORE 

To meet the wide range of installation capabilities and 
requirements, an upward compatible three-level Structure for 
tne CORE system was selected. Tne aim was to accomodate wnat 


were considered the most sommon classes of equipment and 
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applications. Tne most basic level of tne CORE system deals 
mele iy with OUTpUL. There is no interactive capability and 
the segments are of the temporary type only. This level 
fmisi1s5ts Of the output primitives and tneir attributes, 
viewing transformations and device controls. 

ive next level adds the ability to retain selected 
Sseements. I[t still is limited to output only operation. The 
Mestollity and hignlignting segment attributes also are 
included. The third, dynamic level, allows use of the input 
capabilities. This is the level at which interactive 
graphics is supported. Lt orovides wall the “functions 
intended to make up the complete core system: 

1) Output primitives and their attributes 

2) Viewing transformations 

3) Device control 

4) Temporary and Retained segments and tneir attributes 

5) Input primitives 

5) Image transformations 

Level three is further divided according to the 
Capability for image transformation: 

SA) Two-dimensional translation only 

SB) Two-dimensional translation, rotation and scale 

3C) Tnree-dimensional translation, rotation and scale 
AS with all of the levels, these subd-levels are also upward 


compatible. 
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Complications with such a level structure are likely to 
arise at installations where tnere is a combination of 
different graphics devices. What is envisioned for such a 
facility is a body of device independent code linked to 
individual device drivers. The intent is to share as much of 
the independent code as possible, thereby keeping as much to 


the objective of probability as feasible. 


H. ENVIRONMENT INTERFACE PROBLEMS 

Despite a great deal of effort to make the CORE syStem a 
stand-alone entity, operating systems and programming 
languages still impact upon it. For instance, there is no 
Stanaard way to nagké device driver routines available to the 
application when the system is invoked. Methods can vary 
widely depending upon computer and operating system 
capabllities. Another problem is the case where a system 
message 1S Sent to a terminal where the CORE system has been 
invoked. The state of the display may be changed without the 
System being aware of it. The consequences of this depend on 
the situation, but system reliability will certainly be 
degraied. 

There is as yet, no definition of a standard interface 
with programming languages. It is hoped that as more insight 
and experience is gained, a standard language interface will 
be developed and the CORE system will be able to be invoked 


from more than one language, adding a new dimension to its 
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portability. Input/output also has problem potential if the 


programming language and the CORE system are operating on 


the same device. Resolution of tnis is still hignly language 


and device dependent. 
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¥. THE VGM APPROACH TO CORE 


Tne irtual Graphics Macnine (VGM) is Bell Northern 
Research’s implementation of the CORE graphics system. It 
was developed on an IBM 3833 in ANSI standard FORTRAN and 
later modified to operate on a PDP-11/70 under the RSX-11 
operating system. VGM is a FORTRAN based set of subroutines 
with each subroutine corresponding to a CORE primitive 
Dmayocation, attribute setting, or view transformation. The 
package also includes subroutines for control purposes, such 
as initializing devices, opening segments and setting up 
coordinate systems. 

The intended customer market for YVGM is installations 
with low and medium cost “intelligent terminals which are 
capable of sgveneratinzg ezraphical output from fairly high 
level functions and primitives. Terminals not accepting sucn 
high level input will require intermediate software to 
either simulate the functions or break them down to lower 
level primitives compatible with tne device. 

Onder RSX-11, VGM exists as a library of FORTRAN 
subroutines. To use VGM, tne application program is 
created independently as a main program making calls to the 
VGM library. The application source code is then compiled 
independently. The connection with VYGM is made by the RSX-11 


Task Builder. The sanpplication object file and toe 
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appropriate routines from the VGM library are linked into a 
Single task by that RSX utility. 

Included in the VGM library is tne particular subroutine 
that establishes communication between YGM and the selected 
device. This segment of code nas to be created specifically 
for the installation where YGM is to be implemented. This 
routine, SELSTR, is the only executable code in YVGM that 
interfaces witn the device driver. Graphical data is passed 
between YVGM and the driver via a COMMON block of memory. 
What SELSTR does is set tne necessary flags to control tne 
concurrency between the application task (linked with VGM) 
and the selected device driver tasks. Each device driver 
exists aS a Separately compiled and linked task. Under RSX, 
vefore invoking any driver from VGM tnese tasks must be 
INSTALLed by the user. 

In VGM, syntax is a very minor issue. Since tne parent 
language is FORTRAN, and the entire system is based on tne 
subroutine call, the only syntax is the manner in which the 
hecessary parameters are passed. 

It snould be enphasized that YGM does not implement tne 
CORE egraphics system exactly as Set down in the 1979 GSPC 
report. There are a number of differences, whicn may be 
grouped into four general categories. 

A. FUNCTIONAL DIFFERENCES 
In this category the end result of ae series of 


operations in YGM is the Same as that specified by CORE but 
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the mechanism for achieving the result iS not the one 
specified in the propesal. 
1. Segmentation 

The CORE system creates a retained Segment or a 
temporary s@gment with a single function specific for the 
particular segment type. VGM uses a two-step process. First, 
a segment type is established. After the invocation of the 
routine to do tnis any segment created will take on the type 
of the one declared. All segments created will be of the 
same type until a new type is declared. 

Retained segments in ¥GM are stored in Transformed 
Display Files (TDF’s). The TDF contains graphical 
information tnat is ready to be translated into a device 
compatible format. All clipping and transformation has been 
meme” betore the data is entered in tne TDF. Should the 
application program specify an operation on a segment, the 
entire TDF is likely to be changed. Segments tnat are 
specified to be temporary do not cause creation of a TDF. 

2. Attributes 

Like CORE, VGM partitions attributes according to 
their application to either segments or primitives. Both 
systems further divide the set of attributes according to 
their changeability within the program, dynamic attributes 
being tnose that are subject to change by tne application 


program after their initial declaration and Static 
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attributes being those that are not. In CORE tnere are no 
dynamic primitive attributes. VGM, however, does have a 
eroup of primitive attributes tnat it labels as ‘dynamic. 
Wach member of the set of VGM dynamic primitive attributes 
is also a member of tne set of static primitive attributes. 

In YGM a static primitive attribute is one that is 
set while a Segment iS open, and tnat once declared, applies 
to all appropriate primitive invocations following it until 
the Segment is closed. Further, for the lifetime or that 
segment it will always apply to the set of primitives 
emeavred with it. <A Static primitive attribute cannot be 
overridden by any otner setting of that attribute anywhere 
in the program. 

If no attributes applicable to a particular 
primitive are set within a segment then dynamic primitive 
attributes may be assigned outside tne segment. Ata later 
time in the program these attributes may be changed. Whena 
dynanic primitive attribute is set, tne segments to which 
the change applies must be specified. I? tne application 
program does not Set either dynamic or static attributes for 
some primitives then default values are used. I[t is also 
possible for the user to Specify his own Set of default 
values. 

The applicability of an attribute to a primitive at any 
particular time in the program can be determined by the rule 


that user specified dynamic primitive attributes always 
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override default values and Static primitive attributes 
always override dynamic ones. 
5S. fhe Viewing Surface 

The flow of graphical information from a segment to 
an output device is viewed by YGM aS a ‘Stream. By 
manipulating streams, toe user carries out tne CORE 
SELECT/DESELECT and ENABLE/DISABLE device operations. In YGM 
when the user initializes a stream, ne is picking a 
particular device or group of devices for output. Devices 
are assigned to a specific stream as part of VGM. A given 
Stream may have more than one device associated with it. 
Changing tnis assignment requires changes to tne VGM source 
code itself. Stream initialization by tne user’s subroutine 
calls accomplishes tne necessary operating system functions 
to link Y¥GM and the appropriate drivers. It is valid for 
more tnan one stream to be in us@ at any given time. 

After initializing the required treams the user 
then selects one or more of them to be used for display. 
Once a stream is selected, all subsequently generated 
graphical output will be displayed on the devices assigned 
to that stream until it is deselected. There is no way to 
address individual devices on the Same Stream. Stream 
operations are not allowed wnile a segment, regardless of 


type, iS open. 
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VGM uses an extra coordinate syStem in translating 
grapnical data from world coordinates to tne terminal 
Physical Device Coordinates (PDC). Between the 
transformation from World Coordinates to Normalized Device 
Coordinates, VGM taxes clipped graphical data and maps it 
onto a view plane in View Plane Coordinates (VPC). The flow 


of graphical data is shown in Figure 1. 
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Figure 1. Flow of ezraphical information through coordinate 
systems 


5. Transfornations 
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In the CORE specification there is a static segment 
attribute called IMAGE TRANSFORMATION TYPE this specifies a 
maximum allowable level of transformation that can be 
applied to a given retained segment. There are four 
allowable levels: 

a. no transformation 
b. 2D translation only 
c. 2D translation, rotation and scale 


a4. 3D translation, frotation and scale. 
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This feature iS not included in VGM. The transformations of 
2D or 3D translation, rotation and scaling may be applied to 
any retained segment at any time in the program. 
S. Text Manipulations 

In CORE, the manner in which text is displayed ona 
device is controlled by, among otners, tne attributes 
CHARPATH, CHARJUST, and CHARUP. The first attribute 
specifies one of four paths in the view plane: up, down, 
rignt or left. AS the sequence of tert is output CHARPATH 
determines where in relation to the last character the next 
is to be positioned. Tiemetirst character is always 
positioned at the CP. The CHARJUST attribute is a 
Somordation of directions, again in tne view plane, which 
indicate where, in relation to the CP, the rectangle defined 


by the output text string is to be placed. Figure 2 gives 


the possible CP locations. 
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Figure 2. Possible position designations of CHARJUST 


The text, depending upon the charjust values will be placed 


in such a way that the CP will be at a junction of a 
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mertical and a Horizontal line. A particular junction is 
identified by its horizontal and vertical position labels, 
e.g. left, top = point a; ‘center, off = point bd. The 
CHAROP attribute is a vector from the origin in World 
Coordinates which specifies the ‘up direction for the text. 

These three CORE attributes are not specifically 
implemented in VGM. Instead, their functionality is included 
in the VGM attributes CHARPLANE, CHARSIZE and CHARSPACE. The 
text string orientation is defined by the CHARPLANE (a 
vector in World Coordinates originating at tne CP) and a 
"string extent vector. The string extent vector is obtained 
from the CHARSPACE and CHARSIZE attributes. Figure 3 


illustrates the components of these two attributes. 
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Figure 3. CHARSIZE and CHARSPACE attribute components 


45 





The string extent is the result of multiplying the vector 
“v° by the number of characters. ‘V° originates at the CP. 
The boxes containing the tert Characters will be in the 
character plane with their lower left cormer on the string 
extent vector. A wide variety of directions the text may 
follow stems from the fact that values for the attribute 
components can be positive or negative. 
7. Visibility 

In CORE tnere is a segment attribute called 
VISIBILITY which, if “on , means to display a specified 
Segment on the output device and, if “off”, to remove it 
from the screen. This capability also exists in VGM where a 


segment may ve POSTed to make it visible or UNPOSTed to 


remove it from the picture. 


B. CORE FUNCTIONS NOT IMPLEMENTED BY YGM 

The following list of CORSE functions are not implemented 
at all in VGM: 

1. pen attribute 

2. marker symbol attribute 

eepick id aatrri bute 

4. naming of primitives 

9- view_up vector 

6. some inquiry routines 

7. terminate_, disable_, and enable group routines 


8. batch update 
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9. escape mechanism 
10. nignliegntine 
11. hierarchical level structure 


12. acceptance of asynchronous input 


C. FUNCTIONS IMPLEMENTED BY VGM NOT IN CORE 
SPECIFICATION 
1. Primitives 
The following primitives have been added to VGM: 
a. rectangle 
db. are 
Cc. polygon 
ad. flood 
The flood primitive is for use with bit mapped, 
color devices. Flood locates tne CP and establisnes tne 
smallest area surrounding it bounded by arcs or lines. This 
area is then filled with a user specified color. If the CP 
is mot enclosed then it is possible to flood tne entire 
display surface. 
2. Attridutes 
For terminals capable of color graphics YGM adds a 
BACKGROUND COLOR attribute and an ADDITIVE MODE attribute. 
The former is self explanatory. The latter determines how a 
declaration of any new color attribute is to be treated. If 
ADDITIVE MODE is "on then the bit pattern for the ola color 


is logically ORed with the bit pattern for the new color, 
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and tne resulting pattern becomes tne value of E2e 
attribute. Otherwise the new color bit pattern simply 
replaces the old one. 

A BLINK attribute is implemented in ¥YGM, wnicn is 
intended to be one method of replacing the CORE system 
HIGHLIGHTING attribute whicn has been left out. 

5. Other Features 

In VGM, there is amechanism for modifying a 
Segment after it has been closed. This is the EXTSEG feature 
whicn effectively re~opens the segment and allows additional 
graphical information to be appended to the existing file. 
The feature only allows addition of information and requires 
that the CLOSEG command be issued after the addition is 
complete. 

If a egraphics device that iS currently in use has 
both input and output capabilities, VGM will, if directed by 
the application program, back transform input coordinates 
from Physical Device Coordinates to World Coordinates. CORE 
will only vdack transform to Normalized Device Coordinates. 

VGM’s error nandling and debugging aids offer more 
than is required by the CORE proposal. In YGM tne user has 
the capability to specify tne maximum tolerable error 
severity and the maximum tolerable number of errors. If 
either maximum is exceeded, tne program will terminate. Wnen 


errors are detected, anentry is made into an error trace 
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file. This file is intended to be a debugging tool. It 
contains the error cede number, a drief description of the 
error, the relevant parameters involved in the error, the 
name of tne routine in wnicn the error was detected and the 
result of the error (corrected, ignored, default 
substitution or program termination). 

An option tnat GSPC left open to imp ementors was 
how to treat non-graphical data sent to a terminal deine 
used for CORE graphical output. Typically, tnis mignt be 
parent language I/O in the form of write statements or a 
system message to the particular terminal. In VGM there is a 
SET POSITION function which tdentifies an NDC position 
specifying wnere non-grapnical output is to appear on tne 
screen. This output is affected by neither attributes nor 


the CP. 


D. EQUIVALENT FONCTIONS WITH DIFFERENT NAMES 
Tnis is tne simplest category of differences between 
CORE and VGM. SBelow is a snort list showing equivalent 


functions in CORE and YGM. 


CORE name VGM name 
charprecision cnarquality 
detectability pickability 
highlightine blink 
world coordinate modelling transformation 


transformation 
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The device driver iS the connecting link between YGM and 
graphics hardware. Its purpose is to take graphical data 
from VGM via the designated COMMON storage area and 
construct an instruction in a format compatible with the 
Berticudar dé@vice it 1s written for. The software for tne 


device driver is divided into 6&6 modules. 


A. THE DEVICE CHARACTERISTICS TABLE 

This table is a COMMON block of variables describing the 
Characteristics of the graphics device for which the driver 
is written. It is implemented as a BLOCK DATA source program 
and is accessed by all of the executable modules of tne 
driver. It is initialized wnen the module is compiled and is 
treated as read only by all of the routines referencing 


it. 


B. THE STREAM INFORMATION TABLES 

This is anotnmer COMMON block of data which holds’ tne 
current value settings for attributes for each stream. The 
table is updated by tne driver routines as the values are 
changed. #nen the BLOCK DATA source file is compiled, tne 


default attribute values are set. 
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C. THE RUN TIME INFORMATION TABLE 

This table, like the stream information table is subject 
to continuous update by the device driver routines. It 
contains the buffer that holds the instruction to be sent to 
the graphics device. Pointers required for Keeping current 
positions in the instruction buffer (CODBUF) are also in the 
run time information table. In addition there are variables 
for the identification of the debug file and several nost 


computer related values. 


D. ROUTINES EXECUTING ¥GM PRIMITIVES (OnLIB1) 

This module is executable code that is intermediate 
between VGM and the device instruction creating portion of 
the driver. Its routines are invoked from VGM and it in turn 
calls routines to create the appropriate data to fill 
CODBUF. OnLIB1 is graphics device independent but is nost 
machine dependent. Contained in OnLIB1 is the OnEXEC routine 
that is tne only executable code in tne driver software that 


communicates with Y¥YGM. 


BE. DEVICE INDEPENDENT LIBRARY OF SHARABLE ROUTINES (SKELIB) 

This collection of routines iS a set of device 
independent operations that are optionally available to 
OnLIB1. These routines perform operations like projection on 
SeepLane , clippine, image transformations, line style 
generation etc. For nignly capable devices which perform 


these taSks themselves OnLIB1 would not reference SKELIB but 
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instead cause the specific device instructions to oe 
generated. For devices that lack some of these features in 


nardware, SKELIB provides software sinulation. 


F. DEVICE DEPENDENT ROUTINES GENERATING INSTRUCTION CODES 
(OnLIB2) 

toes set of subroutines fills the instruction buffer 
witn instructions and data specifically formatted for tne 
target device. Each byte of CODBUF must be precisely set to 
be compatible witn the graphics device. OnLIB2 builds tne 
full instruction and, when complete, causes it to be sent to 
the terminal. The communication with the terminal is done 
with MACRO routine QWRITE which uses the host computer’s I/O 
communication facilities and treats tne graphics device as 
an I/O port. 

meee On the device drivers share tne stream information 
table and SKELIB. Each driver installed with YGM however 
must contain each of the other four modules. The inter- 
connection of tne various device driver modules is snown in 


Figure 4. 
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Figure 4. Interrelationship of Device Driver Modules 
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A. SOFTWARE 

As stated in tne introduction, the purpose of tnis 
research was to lay the groundwork for a detailed study of 
the CORE graphics system. A great deal of progress has been 
made in this effort. Tne YGM implementation of tne CORE 
system is inStalled at the Naval Posteraduate Scnool and is 
capable of operating with tne Tektronix 4014 storage tube 
display terminal. The SyStem has pasSed the initial Stages 
of testing. Additionally, algoritnms nave been developed and 
implemented on a limited basis for expanding the VGM 
software to interface with tne Ramtek RM-9400 egrapnics 
system. These portions of the project are discussed ina 
detail in Appendices A and B respectively. 

A less tangible, but equally valuable result or this 
Study is tne experience and insight gained with botn CORE 
and the V¥GM implementation. Appendix C is one product of 
this new Knowledge. It is a brief tutorial on programming 
with YGM and is written specifically for the Naval 
Postgraduate School installation. The tutorial is not 
intended to replace the Bell Northern Research JUser’s 
Manuals. It is meant to be used in conjunction with tnem and 
deliberately avoids details which can easily be found by 


referencing them. 





B. CORE EVALUATION 
The CORE system is currently only a proposal and as such 
it is intended for thorough Scrutiny by the eraphics 
community. In researcning tnis sudject a number of issues 
have been identified which may provide a framework for an 
evaluation of tne system. This collection does not purport 
to be exhaustive but is presented to provide a base for 
future work. 
1. Portability 
The prime issue to be evaluated is that of program 
portability. This nas already been discussed in deptn in tne 
GSPC proposal and summarized in this report in Chapter III. 
In tne course of this study some different perspectives on 
the problem have come to light. It appears that there might 
be hierarchical levels of portability other than tnose 
listed in the GSPC report. Graphics devices, computing 
systems, operating systems and CORE implementations are all 
variables in this area. Another way of classifying the 
portability of a program mignt be in terms of these 
environmental factors. For example, some programs may be 
portable from one device to another as long as the computing 
environment is not changed. Others may survive a change of 
computing machinery provided the operating systems are the 
Same. Conversely, changing operating systems rather than 


computers mignt be tne defeating factor in a programs 
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portability. Yet another possibility is that different 
implementations of CORE may be tne reason for changes in a 
given program. 

It would be difficult to develop furtner tne portability 
issue from this point of view until a variety of 
environments exist for side by side comparisons. The 
presentation of this perspective is recorded nere so that 
wnen such facilities are available its validity can be 
considered. 

2. Implementation Effort 

To gain wideSpread acceptance the CORE system must 

ve easy to implement. Criteria are needed to measure tne 
difficulty of implementation. The following list presents 
questions whicn may serve as possible evaluation mecnanisms 
for this: 

a. Can the implementation be reduced to Simply 
following some kind of implementation 
“aleorithm ? 

b. Does the design of the implementation 
favor one type of device over another? 

c. Does the design of the implementation 
favor one computing environment (either hardware 
or operating syStem) over another? 

d. What tradeoffs in portability have to be made so 


that implementation can be facilitated? 
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As is true of almost all standards in tne computing 
industry the CORE system does not take full advantage of the 
hardware capability of many installations. It was never 
intended to meet all pessible needs. Nonetheless a means of 
assessing tne loss in device capability under tne CORE 
system should be establisned. A guideline for determining 
wnen tne gains from using CORE are outweigned ty the losses 
from not utilizing the full power of the device would be a 
nienly desirable tool, particularly for facilities 
generating a wide range of graphics applications programs. 

4. CORE Capability 

Pernaps tne most difficult and controversial 

question in the evaluation of CORE is whether is 
capabilities really are sufficient for most grapnics 
programmers. Further, how adaptable to future needs will the 
System be? Is hardware tecnnology likely to progress to a 
point where CORE is no longer adequate as a standard? Is it 
likely that computer graphics will expand into areas tnat 
CORE was never intended to serve? Certainly none of these 
issues will be resolved easily. Eacn question in itself 
could be a topic for detailed analysis. They are presented 
nere just to suggest areas for further study. 
C. OUTLINE OF CONTINOING DEVELOPMENT OF THE NPS SYSTEM 

In the course of this study some ideas have been 


formulated for a methodology to direct continuing work on 
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the project. This is only one workers point of view and it 
should serve as a guide ratner than an absolute to follow-on 
workers. 
1. ¥GM 

Tne first order of business snould be to modify tne 
Bell Northern Researcn test routine, AXPAK, so that the full 
range of VGM functionality can be verified. Tnis would 
entail construction of appropriate overlays for tne test 
package so that tne large amount of object code can 0be 
accomodated on tne limited PDP-11/50 memory. Once this is 
accomplished, AKPAK can serve as a benchmark program for 
testing additional drivers tnat are added to VGM. Using 
AKPAK as a benchmark should also aid in Studying other 
portability issues. 

2. Device Drivers 

tyes pattem for writing tne code that interfacés tne 
device independent portion of a software driver and the jn id toe 
949@ has been establisned. Further, it nas been partially 
implemented and tested. The next step is to complete the 
remaining subroutines in tne O4LIB2 (device dependent 
routines) module according to the algorithms provided in 
Appendix 8B. Once a new O4LIB2 nas been built it can be 
incorporated into ¥VGM and tested, first as a Peale entity 
using the provided DDTEST program and then as a fully 
inteerated part of VGM using AKPAK. 
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By no means would this complete work on tne Ramtek 
driver. After the O4LIB2 work is completed tne driver would 
still fall far snort of taking full advantage of tne power 
of the RM-94090. A topic of study all its own would be the 
modification of the "device-independent sections of tne 
driver code to put the sopvnisticated features of the RM-946¢ 
into use. 

An ancillary project would be to develop yet anotner 
driver for a new graphics device. The object of this study 
would not be to merely expand the capabilities of the 
existing VGM system. What it is hoped would emerge from such 
research is a pattern for writing device drivers. Such a 
formula, if it exists, would be a very useful tool for 
further expansion of YGM without the necessity of re- 
learning already established techniques. 

5S. Portability 

With a fully operational YGM system and a variety of 
devices available for use, portability testing can begin. 
The suggestion is to direct the work along lines mentioned 
earlier in this chapter in section B. After varying the 
2Taphics devices and studying the system behavior over a 
variety of them, work should proceed to studying program 
benavior under cnanges in tne computing Environment. Otner 
Operating Systems, other computers, and other CORE 


implementations are available for sucn rese@arcn. Tnis 
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variety of environments in 3 Single location would provide 


an excellent test bed for tnorouegn evaluation of tne CORE 


Standard. 
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APPENDIX A. IMPLEMENTATION OF ¥GM AT NAVAL POSTGRADUATE 


o CHOOL 


The aim of this portion of the project was to gain 
insight into the operation of VGM and to install a working 
version of it on the Naval Postgraduate Scnool’s grapnics 
facility. Bell Northern Research (BNR) of Ottawa, Canada 
supplied tne school with a tape containing tne source code 
for VGM, version 1.1. and two device drivers. One driver was 
written for a Chromatics color graphics, raster scan 
terminal and the other for a Tektronix 4901X storage tube 
terminal. A Teetronix 4214 was readily available at Naval 
Postgraduate School and, being a simpler device, was deemed 
the beSt choice for inStalling and testing VGM. 

On the same tape as the ¥GM and device driver software 
were several command files to aid in installing the system. 
These command files did such things as compile tne source 
modules, install libraries and build tasks. Their inclusion 
was intended to Save some user time and effort and to nelp 
avoid erroneous or incomplete system commands that might 
arise during any of the initial Stages of software 
installation. 

The plan for implementation was the following: 


A. Compile all of tne source modules making up YGM. 
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B. Convert the YGM object code into a FORTRAN library under 
RSX. 

C. Compile all of the source modules making up the Tektronix 
device driver. 

D. Link tne object code from tne device driver compilations 
into a single task called O2DRIV. 

B. Test tne driver separately from ¥VGM by using a test 
routine supplied by Bell Northern Research. 

F. Install O2DRIV under RSX as a task available for 
concurrent use. 

ce. Test VGM itself using the Bell Nortnern Research supplied 
test graphics program AXPAK. 

Before any of the installation could begin, tne software 
on the tape had to be made easily accessible. This was done 
by copying it onto tne RSX on-line disk storage. <A copy of 
the BNR software may be found under directory DP@: [281,211]. 
This copy of tne source code is intended to remain unedited. 
Any changes to the code during 7GM installation were made by 
transferring original copies to a working directory and 
editing there. To generate object code the modules necessary 
for V¥GM and the device driver compilation were PIiPed to 
directory DP3:[201,218]. Once the source code was available, 
the command file YGMCOM.CMD was executed. VGMCOM.CMD nad to 
be modified somewnat to make it compatible with tne fF4Pp 


compiler. The BNR software was written under an older PDP 
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version of FORTRAN so tne compiler commands had to be 
adjusted accordingly. 

In all, VGM contains 12 output modules and 7 input 
modules. Each module is, in turn, made up of several 
Subroutines grouped by the particular function they perform. 
For example, the output module INISTR (INItialize STRing -- 
mamed for the first of the component sudroutines) contains 
16 separate subroutines all naving to do witn either stream 
or segment manipulations. There are also two block data 
modules and a teSt program. 

Once object code was generated for all of tne YGM 
routines, command file VGMLIB.CMD was executed under the RSX 
LIBRARY utility, creating a library of all tne executable 
routines concerned with input and output. 

Tne compilation process was repeated for the source code 
modules for the Tektronix driver. Command file O2DCOM.CMD 
accomplished this. The device driver modules consist of two 
“libraries” which manipulate the device independent 
information coming from YGM. A third library, O2LIB2, does 
the actual creation of instructions to the Textronix. O2LIBe 
is the portion of tne device driver that links VGM and the 
terminal. There are also some block data modules which set 
up communication areas between the device driver and YGM and 
also provide specific device parameters where needed to doth 
VGM and the device-~independent portions of the driver. Two 


MACRO modules are included to handle input and output 
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communication between the device and the operating syStem. 
The rest of the driver related modules concern themselves 
with interfacing the device independent parts of the driver 
and VGM itself. 

Like VGM, the object code for the device driver modules 
are built into a library under RSX by file O2DLIB.CMD. This 
library however iS only a temporary holding area for the 
driver object code. It is referenced by tne file O2DRIV.CMD 
and the object modules are linked together into a single 
task called O2DRIV. 

With VGM existing as an object library and O2DRIV as an 
individual task the preliminary work is done. Testine is 
accomplished in two stages. The first is testing the 
functionality of the device driver independent of YGM. The 
test program, O2TEST, was provided by Bell Northern Research 
and was compiled with the rest of the driver routines and 
block data programs. The file O2TEST.CMD links tne test 
program, the driver library, and the bdDlock data into a 
single executable task called TEKTEST. TEKTEST exercises the 
driver’s functionality fully and 15 available for use in 
directory DP3: [281,219]. 

After tne driver was satisfactorily tested alone, tne 
task O2DRIV was INSTALLed under RSX. The INSTALL feature is 
an RSX utility tnat activates a specified task and maxes it 


available for invocation from another active task. 
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The next step is building the VGM test task. The test 
routine, AKPAK, is also supplied by BNR and is intended to 
thoroughly test V¥GM and any Selected device driver. The 
command file provided to build tne AKPAK task is VGMTKB.CMD. 
The initial attempts to build the test program resulted ina 
Task Builder diagnostic indicating tnat not Qnougn 
contiguous disk space was available for the AKPAK task. This 
was partly a result of the fact tnat AKPAK and tne 
associated YGM library routines require avery large block 
or disk storage. This is also indicative of anotner 
potential problem. Since the AKPAK test is such a large one 
it is not likely to fit into tne available core memory. It 
will most likely require construction of overlays to run on 
the limited memory resources of the PDP-11/5¢@ at NPS. 

It was decided that at least for the initial phase of 
Study to follow a Somewhat shorter and simpler testing path. 
Rather than become involved in constructing overlays and 
possible changes in the Structure of AKPAK, a more limited 
test program would be written. Since one goal of this part 
of the work was to get an Operational VYGM system it was 
deciied to at least ensure the proper interfacing between 
the user program, VGM and O2DRIY. 

Toward this end, a much Simplified test program was 
written, called VGMTST. It was linked witn YVGM and tne 
necessary block data routines by file YVTST.CMD. VGMTST 


exercised several of the 2-dimensional drawing, move, and 
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marker primitives, the low quality text capability and the 
SET POSITION feature. In addition, some of tne device and 
segment control functions were also tested since their use 
is essential for any VGM operation. 

The execution of VGMTST was quite successful. The 
drawings on the Tektronix screen appeared as expected. The 
task 1s available for use under directory DP3:[201,218]. To 
use the test routine, turn on the Tektronix 4014 and log in 
under RSX by the standard procedure. Enter the proper 
directory by typing 

SET /OIC = (281,219] 
after tne RSX prompt ( > ). Next, when tne prompt appears 
issue the commands 
>INS O2DRIV 
>RON YVGMTST 
The test program will execute and tne resultant egrapnics 


will appear on the screen. 
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APPENDIX B. CONSTRUCTION OF A DSVICE DRIVER FOR THE RAMTEK 


A. DEVICE DRIVERS 

Bell Northern Research’s device drivers are identified 
by unique integer designations, the particular integer being 
incorporated into tne driver name and the names of tne 
modules that comprise them. The modules, and subroutines in 
them, specific to the Chromatics driver all begin with an 
Ol- identifier, for example, O1LLIBe or O1LMOVE. The Tektronix 
4014 software is device driver #2, tous its names are all 
prefixed with an O2-. Also provided is a driver which shares 
the Tektronix 4014 code dut is to be used with tne Tektronix 
4919. This uses the O3- prefix. Only the OSEXEC (tne 
interface with tne VGM software) routine nas tne prefix, the 
rest of the driver uses the Tektronix 4014 code. For the 
Bewts nes to De written as part of this study, tne C4—- prefix 
was selected, being the next in the sequence. 

The target device in this portion of tne study was the 
Ramtek RM-949%, a very powerful and sophisticated color 
raster scan graphics device. Adaptation of a similar driver 
seemed tne best course of action. The Chromatics grapnics 
terminal is also a color, raster device though not nearly as 
advanced as the RM-9400. Nonetheless its driver is readily 


available and is already adapted to the PDP 11 /R5% 
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environment. et provides a good starting point for 
developing tne Ramtek software. 

The initial intent in the construction of a device 
driver for tne RM-9400 was to leave tne Chromatics driver 
intact as far as possible. Tne module SKELI3, wnich contains 
the device independent hardware feature simulation routines, 
was left unchanged. The Stream Characteristics Table nad to 
be modified only sligntly to include the new device. The Run 
Time Information Table for tne Ramtek is simply a copy of 
the one provided for the Chromatics driver. The same is true 
for O4LIB1l with tne exception of tne O4EXEC routine. 
Modifications to O4"XEC were very slight. Inclusion of the 
new O4EXEC routine did necessitate cnanges to tne YGM 
software in the INISTR and SELSTR (SELect STRing) modules. 

The bulk of the work in writing One new driver will be 
in developing a new O4LIBe. Creation of a new Device 
Characteristics fable is also important. The latter requires 
an item by item reviewing of tne table variables and 
providing the appropriate values as they pertain to the R&M- 
9490. Details of what entries should be made are in the ENR 
“Skeleton Driver Installation Manual”. In this study very 
little of the RM-94040’s capabilities were exercised and the 
importance of the Device Characteristics Table was secondary 
to getting a rudimentary system in operation. As the device 
driver develons into a more refined form and incorporates 


more of tne RM-9420"s Capabilities, tne Device 
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Characteristics Table should be reviewed and updated 


continuously. 


B. RAMTEK RM-9460 INSTRUCTION FORMAT 

Before writing any of tne routines, a Knowledge of the 
format of an RM-9400 instruction is required. The RM-9402 
instruction is a variable length butfer of 16 bit words. The 
first 8 odbits of the first word contain the code for the 
function the device is to execute. For exa ple, an operation 
code of 96H (Ramtek mnemonic INIT) initializes the device; a 
code of 35H (Write Vector, Unlinked -- mnemonic WV) is a 
line drawing instruction. The operation code determines how 
much more of the instruction buffer the RM-940% needs. For a 
very simple instruction like INIT, once the operation code 
is read, the rest of the buffer is ignored. For something 
like a line drawing, however, the device will require a 
number of extra words of information before it can execute 
the instruction. The extra words will, aS a minimum, have 
to indicate tne end points of the line, and may include the 
foreground and background colors aS well as the line style 
and thickness. Depending on the operation, some of tne 
additional instruction words are essential and some are 
optional. In most cases, if a piece of data is required and 
is not specified, a default value will be used. The 
architecture of tne RM-940@@ is sucn that it is possible for 


the user to specify the default parameters values. 
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The presence of additional words of information is 
indicated to tne Ramtek by flag bits. The last 8 bits of tne 
first word are the primary set of flags. Only three of tnese 
are involved in @xtendine the size of the instruction. The 
five high order bits of tne low byte modify tne execution of 
the operation code as indicated in the following table. 


bits 6 4& 7 code for the mode of addressing 
refresh memory 


bit 5 Selects additive mode oY 
text output 


bit 4 reverses foreground and 
background colors 


bit 3 sets device to process 
bytes in a word in reverse order 


1% is the tnree lowest bits tnat indicate how many 
additional words of data will be in tne instruction. Bits 2 
and 1 each indicate whether a particular operand flag word 
will be in the instruction buffer. 

If bit 1 in set, operand flag word #1 ° ®4(OF1) will 
immediately follow the word containing the operation code 
and the primary flaes. OF1 is another Set of flags each of 
which corresponds to additional pieces of information in the 
instruction. The settine of one of the 16 bits in OF1 means 
that one or more words of data will follow. The order of the 
additional data will correspond to the bits of OF1, from 
lowest to highest. 

A sample bit pattern might be 


9208 @GG1 SOOO BG10 (81G2H) 
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This would indicate that two additional pieces of data (one 
for each ‘1 bit) are in the instruction buffer following 
Tan. in this Gase the two bits that are set mean that 
“foreground data and “line dimension data are present 
(pits 1 and 8 respectively). Tne foreground information is 
Simply an integer index to a color table in Ramtek refresh 
memory and only requires a single word of storage. Tne line 
dimensioning information is more complex consistinz of a 
pattern code anda repeat code (interpretation of tnese 
codes is not important to the current discussion) and 
requires two words. These two words will follow tne 
foreground word in the buffer. The code that the RM-942¢ 


would execute is snown symbolically in Figure 5. 
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| foreground color index 
) 
‘ 
a 
1 


~ Line code word i 


a a cep 0 we SO ee See a SF ee SS ce ee, Se SS ee ee ce Ge oo 


line code word 2 
J 
J 


mp HE que > > “GE Eo a, GES SC AOA“ ees SSF a OD ee SE eee 


Reeune 5. Instruction Buffer with OF1 and Associated 


Parameters 


Bit 2 of the primary flags indicates the presence or 


absence of ‘operand flag word 2 (OF2). If flag bit 2 is set 
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then OF2 will immediately follow OFl. If flag bit 2 is Set 
and flag bit 1 is not, tnen tne word immediately following 
the operation code word is OF2. OF2 performs exactly the 
same task as OF1 except that only its six least significant 
bits are used. 

Flaz vit 4 in the operation code word indicates that 
text or numeric data will follow OFL, OF2 and tneir 
associated parameters if present. The first word of this 
data will always be an integer indicating Now many 
additional bytes of data will come after it. 

To illustrate, suppose the user wants to draw a line 
from the pixel at Screen coordinates 19€,129 to the one at 
590,500. He further want its color to be tnat of #4 in tne 
color tabdle in refresn memory and his line dimension code is 
Piven by the words 91016 and @0@3H. The instruction buffer 
would be that shown in figure 6. 

To a rough approximation the operation codes for RM-9498¢ 
instructions correspond to VGM primitive and device control 
functions. Similarly, the parameters referenced by _ the 
operand flag words correspond to attribute values. While 
this 1S not always the case it provides a good rule of thumb 
for tne initial development of a device driver. Tnose YG™M 
calls executing a primitive or control function will cause 
fem operation code to be placed in the instruction buffer. 
Those setting an attribute will cause the setting of flags 


and loading of appropriate parameter values. 
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C. SETTING ATTRIBUTES 


1. Storage Reautrements 


Wnen an attribute is set it doe@s not necessarily 
have to take effect immediately. Therefore memory locations 
must be available to store tne values of attribute settings 


until an appropriate operation code using them is loaded 


opcode ; flags 
6211 9181 | @888 9911 
| 
ee a ee 
OF1 
0290 OGYOG1 BAGO BB1O 


~ color table index 

G02 BOOB BOYY 2190 

~ line code word 1 
QY20 001 O200 2901 

~ line code word 2 
O2O0 2O2 OYSS 9011 

~ data length word 
0220 2002 9220 1090 

"x Start coordinate 
Q0O8 2098 9112 012d 

~ y Start coordinate 
0200 2098 9118 9186 

~ -xX @nd coordinate 
Q026 2001 1111 9190 

-y @nd coordinate _ 
6920 O01 1111 0128 


SE GS > Gp GP GPG GSS: GDP ap => ap a > am Ga GS = 


ae ogee oe Oe oe ewe ae SO cee eee Gee Op cee OS OS ee ep ee ee oe ee ogee ee Se ee ee ee ee ge ee OO SF “gs OS Oe 2S ee 6 ge oe @ eee ee aw ee @ ot ge oe 


Figure 6. Instruction buffer for line with specified color 
and style 
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into tne instruction buffer. Tne RM-949@ nas tne capacity 
for setting ee different parameters, each one corresponding 
to a bit in one of tne operand flag words (16 in OF1 and 6 
in OF2). Not all of the parameters that are entered into the 
Ramtek instruction are limited to a Single word. Although 
Some parameters do require only one word there are others 
that need 2 or 4, and in one case id, words of storage. The 
total storage required for tne 22 parameter settings is 47 
words. A global, integer array of 47 elements named PARAM is 
set up as part of a BLOCK DATA program to store these values 
aS they are Set. Two additional “read only arrays are also 
part of tnat BLOCK DATA subroutine. Tnese aid in referencing 
the PARAM array. Integer array PRMPTR of length 22 contains 
indices to tne starting location in PARAM wnere a particular 
parameters values are saved. Bach entry in  PRMPTR 
corresponds to a flag in one of tne operand flag words. 
Blements 1 through 16 of PRMPTR contain pointers to the data 
associated with bits @ tnrougn 15 of OF1. Elements 17 
through 22 do the same for bits @ through 5 of OF2. The 
Second array, PRMSIZ, 15 a parallel array to PRMPTR. Each of 
its integer values is the size, in words, of tne particular 
parameter pointed to by the corresponding element in PRMPTR. 
The values of PRMPTR and PRMSIZ are fixed at compile time 
and remain unchanged throughout the program. PARAM is 

initially set to all zero entries and gets updated as the 


various attribute values are assigned. 
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Tnere are also two logical arrays and tnree logical 
variables involved in keeping track of attribute settings. 
Tne elements of the logical arrays correspond to the bits of 
OF1 and OF2. They are named OFIARR and OF2ARR. If a bit in 
eitner OF1 or OF2 is to ve set by a particular subroutine 
call then tne element in OFLARR or OFZARR tnat corresponds 
will have a FORTRAN value of .TRUE.. The logical variables 
correspond to tne lowest tnree bits of tne primary flag set 
of the Ramtek instruction operation code word. For bit @é 
there is OF2FL, for bit 1 tnere is OFIFL and for dit 9 tnere 
is DFFL. All of the logical variables, including the arrays 
are initialized to .FALSE.. 

Finally, the tnmree words which actually control the 
instruction buffer size must be kept: OF1, OF2, and DLW 
(data leneth word). These are declared as integer variables 
in tne BLOCK DATA subroutine and initialized to zero. 

2. Value Storage Operations 

When 2 subroutine that sets an attribute is called, 
several operations must take place, not necessarily in any 
particular order. One of the required events is that the 
attribute values must be entered into tne proper location in 
PARAM. This is done in a special subroutine called O4LOAD. 
Its essential part is aDO loop wnich fills tne array 
Starting at the location indicated by an element of PRMPTR 
and rll ing the number of words indicated dy tic 


corresponding PRMSIZ value. Along with setting the parameter 
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values a flag markine the fact that they are to be used 
must also be set in either OFI1ARR or OF2ZARR. Also, the flag 
indicating either OF1 or OF2, must be Set, So either OFIFL 
or OF2FL becomes .TRUE.. 
Tne code for any subroutine that sets an attribute 
can be written according to the following algorithm: 
input: parameter values 
begin attribute settine subroutine 
set OFIFL or OF2FL 
if flag in OF1ARR or OF2ARR not set then 
Set OFLARR or OF2ARR flae 
set flag in OF1 or OF2 by adding proper power of 
two 
end if 
store parameter values in PARAM 
end 
Two subroutines nave been written that carry out this 
process. They are OQ4COLR and O4BCOL. The source code for 
them is found under RSX on the PDP-11/50 in directory 
DP3:(301,1]. The subroutine O4LOAD is also found in tnis 
digrectory. 
3. Filling the Instruction Buffer 
The critical subroutine in module O4LIB2 is COPCOD. 
This is the one that controls the filling of the 
instruction. It is invoked by the primitive and control 
subroutines in O4LIB2. The routines that call COPCOD pass as 
a parameter an index to an array containing the Ramtek 
operation codes. These operation codes are set into the 


array OPCODE at compile time. They are deSigned to be the 


Ramtek equivalent of the intended VYGM function. COPCOD gets 
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the actual code from the array OPCODE. The operation code 
and the primary flags are tnen combined into tne first word 


of the instruction buffer. COPCOD also causes the operand 
flagwords (OF1 and OF2), their parameter values and the data 
length word to be loaded if any of them are required. The 
text or numeric data is loaded by the primitive or control 
Rowrine itself. 

The following algorithm Shows the operation of 
COPCOD. The code can be found in directory DP3:[(301,1]: 


input: OPCODE index 

begin COPCOD 
get actual operation code from array OPCODE 
if OFIFL = true then set flag bit 1 
if OF2FL = true then set flag bit 2 
snift Geeracwon mcoce FLO upper byte of first 

instruction word (multiply by 256) 

add flagword to shifted operation code 
load operation code word into buffer 
load OF1 and/or OF2 as indicated by flags 
load parameters in proper order from PARAM 
load data length word if necessary 

end 


As with attribute setting, all subroutines which are 
primitive functions can be patterned after a Single 
algoritnm. Control functions can follow tnis same pattern 
thougn they typically will not require data values to be 
placed in the instruction buffer. The algorithm is: 


input data values 

begin function erecution 
set DFFL (data flag) if appropriate 
set bit 8 of flags 
set data lenegtn word (DLW) to number of bytes of data 
call COPCOD -- pass OPCODE index 
load data values 
@erecute instruction 

end 
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A number of routines nave been written following 


bors algorithm. They includes 


O4D0T place a point at specified coordinates 
O4MOVE change current cursor position 

O4DRAW draw a line between two specified points 
O4SSTR Output a text string 

O4RSET erase tne screen. 


All can be found in directory DP3:(3@1,1]. It snould 0obe 
noted that the routine O45TR, wnich dDuilds an instruction 
for text output, inserts an extra Step before loading the 
data. O4STR receives its text data in an integer array with 
one alphanumeric character per element. The Ramtek requires 
textual data output to be formatted to one character per 
byte. Therefore O4STR must make this conversion before 
loading the data into the buffer. 
4. Testing 

As tne routines were developed tney were tested for 
operability. The testing was at a very low level simply 
checking that the instruction buffer was being properly 
constructed and transmitted to the RM-9400. All of tne 
Toutrtnes developed in tnis portion of tne study nave been 
successfully checked in this manner. The test programs are 
modularized, each being called by a master routine called 
DUMTST. The individual test routines are named LINTST (LINe 
drawing TeST), PTTST (Foinf placement TeST), TXTST (Text 
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output TeST) and COLTST (COLor selection TeST). Their source 
code can be found in directory DP3:{301,1). 

All of the routines developed were originally part 
SeertemOolnhik2 modube of the Chromatics driver. A copy of the 
onpieinal software is available im directory DP3:({5,3]. After 
modifying the names to conform with the selection of #4 as 
the identifier for the new device driver each subroutine was 
removed from the module and treated as a separate entity. 
This was done for ease of editing and troublesnooting. To 
support bags process command files were created to 
facilitate repetitive compilation and task building 
operations. The files COMP.CMD and TCOMP.CMD in directory 
DP3:{381,1] cause tne compilation ot all tne driver software 
and all tne test software, respectively. File DUM.CMD builds 
the eest task  DUMTST.TSE, by linkine tne modified 
Subroutines, the BLOCK DATA programs and the test routines. 

AMone MeL Ae UN TESterOulinesessome short pieces of code 
have been included to accomodate testing. The important ones 
agemeamiNIT, which inserts the color table into the Ramtek 
refresh memory, and BIGTXKT, which causes text output to be 


printed in a larger tnan normal format for viewing ease. 
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APPENDIX C. PROGRAMMING WITH ¥GM 


Grapnics programming using VGM is actually a highly 
Specialized use of FORTRAN. Because of tnis, all tne rules 
of PDP—11 FORTRAN apply aS well aS those of the graphics 
System. When usine GM the programmer venerateS a4 main 


program which references a library of graphics subroutines. 


A. SETOP 
VGM is initialized by three essential statements. First 


CALL INIT 
GENT Ti alie ) 


Starts the VGM session. It Sets the variables required by 
Bova the operating system and VGM itself. The routine 
ensures that each time VGM is invoked it is in the same 
Starting state. Immediately following tnis, 


CALL INISTR(n) 
(INItialize STReam) 


activates the device dependent driver software for stream 
“n°. It sets device parameters and uses the operating system 
process nandling capabilities to allow application program 
Seeess to tne particular device or devices on tne stream. 


Lastly, 


CALL SELSTR (n1) 
(SELect STReam) 


directs all graphics output to stream ‘ni’. If anotner CALL 


SELSTR (n2) instruction is encountered before a CALL 
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DELSTR(n1) instruction, tne grapnics output will go to bdbotn 
streams ni and ne. I[t iS mandatory that e@ach stream be 
prepared by a CALL INISTR(n) before it is selected by a CALL 


SELSTR (n). 


B. ENVIRONMENT SPECIFICATION 
1. The Coordinate System 

In VGM, the user defines hisS #rapnhical world in 
arbitrarily selected “world coordinates . These coordinates 
are the medium through wnichn ne communicates positional data 
to the system. Y¥GM processes those world coordinates through 
a series of viewing transformations and eventually derives 
“normalized device coordinates (NDC). The NDC’s are real 
values ranging from 9.@to01.@and ar@é mapped onto tne 
physical device selected for viewing. A picture in NDC is 
maeependent of dny perticulear graphics device. 

For YVGM to properly execute the string of required 
coordinate transformations, tne Normalized Device Coordinate 
System must be Specified before World Coordinates. With 


CALL NDCSPC (nstrm, widtn, neignt) 
(Normalized Device Coordinate SPeCification) 


a rectangular portion of tne view surfaces of terminals on 
Stream “nstrm’ is defined. “Width” and “height” are real 
numbers ranging from @.8 to 1.0. Tney indicate tne relative 
part of that dimension of the view surface that iS to bde 
used. One or tne otner must be 1.8. Tnerefore, eitner tne 


full screen width or the full Screen neight will be used. 
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The remaining dimension will be proportionately adjusted. A 
statement such as 
CALL NDCSPC (1,1'.@,.75) 
will set up tne devices on stream #1 so that a viewing area 
usine the full width of the Screen iS made availatle. The 
heignt will be 3/4 as large as the width if that much is 
available. If a dimension specification is too large, the 
maximum available is used. The NDCSPC command normally is 
used only once for each stream. 
2. The View Surface 

After setting the total viewing area available, 
“viewports are asSigned to the streams by 

CALL VIEW (nstrm, xmin, ymin, xmax, ymax) 
A viewport is a portion of the available surface (NDC space) 
that will be used, up to, but not exceeding, tne total 
declared surface. “Xmin’, “ymin”, “xmax’, and “ymax” are NDC 
values and must be within tne bounds specified in tne NDCSPC 
call. A viewport declaration stays in effect until a new one 
meme ctared. The viewport may be changed as often as tne 
user desires in the main program. 

The window is the counterpart of the viewport in 
the world coordinate system and is set by 

CALL WINDOW (nstrm, xmin, ymin, xmax, ymax) 
The parameter values except for ‘nstrm” are in World 
Coordinates and are arbitrarily selected by the user to meet 


nis requirements for clipping and image transformations. 
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PaaS 2s thee part of World Coordinates that the picture 15 


created in. The window iS the work area of the programmer. 
For display, the clipped and transformed images in the 
window are mapped to the NDC space defined by the viewport. 
3. Background Color 
On color capable devices the last environment 
setting operation is to define tne background with 


ORE BORCOL( ival ) 
(BaCKground COLor) 


to s@t the attribute and 
CALL ERASE 
to bring it up on the Screen. 

Poe curren cteversion. of VEM allows selection of one 
of only eight colors available. Selection is done Ddy 
Specifying an integer value between @ and 7 for “ival”. The 
default color table contains black, blue, green, cyan, red, 


Mamenta, yellow, and white, in tnat order. 


C. CREATING A PICTURE 

Witn the devices initialized, and the environment set, 
the next step 1s to open a segment. To do tnis the type of 
the intended segment must first be declared by 


CALL SEGTYP (itype) 
(SEGment TYPe). 


An “itype” value of 1 indicates tnat all subdsequently 
created segments will be non-retained. A value of 2 means 


that tney will be retained. 
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Peter the type nas been establisned, tne segment is 


opened with 


CALL CRESEG (nseemt) 
(CREate SEGment). 


“Nsegmt’ is an integer value that uniquely identifies tne 
Pemurcurar s@€enent. Once the segment 1s open, tne user 
creates his image by invoking primitives and assigning 
attributes. Any primitive attribute values declared before 
closing the segment are static. Declaration of segment 
attributes is not allowed wnile a segment is open. As eacn 
primitive is erecuted its contribution to the total image 
will be displayed. Wnen tne particular image is completed, 
pae 


CNG ie LOS &G 
(CLOse SEGment) 


misemruetion is issued. It is not necessary to specifically 
identify tne segment being closed, since only one is allowed 
to be open at any given time. 

ALtver Closing a s@gement, @ number of options are open to 
the user. He may terminate the session dy normal FORTRAN 
paeeedures or Ae may continue on and manipulate devices, 
streams and segments. He may alter dynamic attributes and 
Speave cadditional segments subject to tne limitations of YGM 
and FORTRAN. 

D. EXECUTING THE PROGRAM 
After creating the source code for a YVGM program it 


Should be independently compiled into an object file. 
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Incorporating the user file and the ¥VGM library into an 
executable task requires tne following command sequence to 
be issued to the RSX Task Builder (for purposes of the 
example, MAIN is selected to be tne name of the user’s 
program): 


TKB> MAIN/CP/FP,VGM/-S P=VGMLY /MP 


ASG = SY: l 
ASG = SY: 2 
ASG = SY: 4 
ASG = TI: 5 
ACTFIL = 3 
MAXBUF = &@ 
FMTBUF = 89 
leh 


Before executing the task (now Stored in file MAIN.TSK) it 
igs necessary to INSTALL the device drivers. For @ach stream 
that will be used by MAIN.TSK. The MCR command to RSX is 
D>INS OnDRIYV 
wnere “n° is the integer identifier for the particular 
driver. Tne command . 
>RUN MAIN 


will execute tne user’s graphics program. 


she. 
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